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(54) Title; DEVICE INTEROPERABILITY 
(57) Abstract 

A device having means for controlling operating modes 
of the device processes control and query data received from 
the second and third electronic devices for managing the 
communication relationships amongst these devices. The 
invention involves a system for communicating between 
multiple electronic devices, such as consumer electronic 
devices or the like, via interconnections such as digital data 
buses. 
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DEVICE INTEROPERABILITY 

Field of the Invention 

5 The invention involves a system for communicating between 

multiple electronic devices, such as consumer electronic devices or 
the like, via interconnections such as digital data buses. More 
particularly, this invention concerns an arrangement for nianaging 
the interoperability of such devices. 

1 0 

Background of the Invention 

A data bus can be utilized for interconnecting electronic devices 
such as television receivers, display devices, video-cassette recorders 
15 (VCR), direct broadcast satellite (DBS) receivers, and home control 
devices (e.g., a security system or a temperature control device). 
Communication using a data bus occurs in accordance with a bus 
protocol. Examples of bus protocols include the Consumer Electronics 
Bus, or CEBus, and the IEEE 1394 High Performance Serial Bus. 

20 

A bus protocol typically provides for communicating both 
control information and data. For example, CEBus control information 
is communicated on a "control channel" having a protocol defined in 
Electronics Industries Association (EIA) specification IS-60. Control 

2 5 information for a particular application can be defined using a form 

of programming language known as CAL (Common Application 
Language). 

Consumer electronics devices are becoming increasingly 

3 0 complex and provide an ever-increasing number of features. While 

coupling these complex devices together via a data bus may be 
necessary to provide a complete audio-video (A/V) system, doing so 
creates numerous problems. For example, certain features of one 
device may require interaction with one or more devices coupled to 
3 5 the bus. A capability of one device may be needed to complete a 

particular operation in another device. Conflicts between the needs 
of various devices may occur. 
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At present, when more that one device competes for the use of 
a common resource, for example a third devi4:e connected on the 
network bus, the first in time controls the device. The other device 
cannot gain access to the common resource until the first device 
5 releases its hold . the resource. This does not pose a problem in 
simple netwoixvo, for example a network comprised of a television, a 
cable box, and a VCR. In such simple networks the VCR is 
"controlled" by the cable box, that is the VCR will only record what 
the cable box is providing. However, in more complex networks two 

1 0 devices, for example a cable box and a digital broadcast receiver, 

may compete for control of a shared resource, i.e., a VCR. 

Summary Of Thp Tnvention 

^ ^ I" "™any control applications it is desirable to discriminate 

against general access to a device. This discrimination usually 
benefits "a single device. In such a case, a special relationship called 
"locking" develops, for either a short or long duration of time, 
between two devices. The locking relationship allows one device to 

2 0 control the access to a second device (i.e., a "locked device"). 

In general there are two types of locking approaches. In the 
first approach, the locked device determines if it can be unlocked 
and/or locked to another device. A request to lock the device is 

2 5 made directly to the locked device. If the locked device cannot 

satisfy the new request, the locked device polls the device which 
locked it (i.e., the locking device) to ascertain whether or not the 
existing lock can be terminated and a new lock be consummated. If 
the locking device does not respond, for example, in the event of a 

3 0 failure, the locked device terminates the lock and establishes the new 

lock. In the second approach, a device wishing to lock another device 
broadcasts a request over the network that any device having a lock 
on the desired device terminate its lock. 

3 5 Generally, in accordance with the invention, a first electronic 

device comprises means for coupling to a data bus and control means 
for controlling communication via the data bus between the first 
electronic device and second and third electronic devices coupled to 
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the data bus. The control means processes control and query data 
received from the second and third electronic devices for managing 
the communication relationships amongst these devices, 

5 In accordance with one aspect of the present invention there is 

provided a device having a means for communicating with at least a 
second device interconnected by a network bus, thereby creating a 
relationship between said first mentioned device and said second 
device, said communication means being capable of receiving query 
1 0 data from a third device. Further, the device has a first means for 
storing information pertaining to the persistence of said relationship 
and a second means for storing information pertaining to a condition 
for terminating said relationship, and a means for controlling 
operating modes of said device in response to control data from said 

1 5 second device. The controlling means is capable of processing said 

relationship information and said query data and of terminating said 
relationship in response to one of said terminating condition and said 
query data. 

2 0 In accordance with another aspect of the present invention the 

relationship information comprises one of a first state wherein said 
relationship is terminated in response to said query data and a 
second state wherein said relationship is maintained regardless of 
said query data. 
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In accordance with yet another aspect of the present invention 
the termination of said relationship in response to said query data 
comprises forming a new relationship between said consumer 
electronic device and said third device. 

In accordance with still another aspect of the present invention 
the controlling means is capable of polling said second device, in 
response to the receipt of said query data to obtain permission to 
terminate said relationship. 

In accordance with still another aspect of the present invention 
there is provided a system having a plurality of devices 
interconnected to one another by a network bus. Each device having 
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a means for communicating, first and second means for storing 
information and a means for controlling the operating modes of said 
device as described hereinabove. 

5 In accordance with a method aspect of the present invention a 

consumer electronic device connected on a network bus, the method 
comprises communicating with at least a second device 
interconnected by a network bus, controlling operating modes of said 
consumer electronic device, storing information pertaining to a 
1 0 persistence of said relationship and a predetermined condition 

pertaining to a condition for terminating said relationship, receiving 
query data from a third device, processing said information 
pertaining to said significance of said relationship and said query 
data, and terminating said relationship in response to one of said 

1 5 terminating condition and said query data. 

Brief Descript ion Of The Drawing 

The invention may be better understood by referring to the 
20 enclosed drawing in which: 

Figure lA shows, in block-diagram form, a system of electronic 
devices coupled together using a data bus; 

2 5 Figure IB shows, in block-diagram form, further detail of a 

portion of the system shown in Figure lA; and 
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Figures 2 through 7 show flow diagrams illustrating the 
operation of the system shown in Figure 1. 

In the drawing, reference numerals that are identical in 
different figures indicate features that are the same or similar. 

Detailed Description of the Drawing?; 

Figure lA shows a system including three electronic devices A, 
B and C, identified by reference numerals 110, 100 and 120, 
respectively, that are coupled together via data bus 130. Devices A. 
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B, and C may be various types of electronic devices including 
consumer electronic devices such as audio and/or video signal 
processing devices and home, control devices. Specific examples of 
consumer electronics' devices include television (TV) receiver, display 
5 devices, cablejbpxes, video tape reco rder (VTR jqjl VCR), direct 
broadcast satellite receivers (such as a DS.S satellite receiver), 
compact disc (CD) units, digital video disc (DVD) units. Home control 
devices include security devices (e.g., cameras, locks), remotely 
controlled switching devices, and environment control devices (e.g., 
1 0 heating, cooling). A system incorporating principles of the invention 
may include more than the three devices shown in Figure lA. Also, 
each device may be a different type of device. For example, a system 
in accordance with the invention might include numerous devices 
throughout a home including TV, VCR, cable box, satellite receiver, 

1 5 audio system, and home control devices. 

In the example shown in Figure lA, data bus 130 includes 
multiple signal paths for communicating data and control information 
between the devices. The bus structure may be serial or parallel. 

2 0 Data communication on the bus may be in accordance with any one of 

a variety of bus protocols such as the CEBus or IEEE 1394 protocols 
identified above. Data communicated via bus 130 can include video 
and audio data. For example, a satellite receiver receiving a digital 
video signal could transfer digital video and audio data via bus 130 

2 5 to a digital tape recorder (DTR) for recording. 

Device 100 includes bus interface unit 102 for coupling device 
100 to bus 130. Bus interface 102 includes hardware suitable for 
receiving data from bus 130 and for transmitting data on bus 130. 

3 0 For example, interface 102 may include registers or buffer memory 

for receiving and temporarily storing data from bus 130 until device 
100 is ready to process the data, and for storing data until ready for 
transmission on bus 130. 

3 5 Interface 102 is controlled by control microcomputer (|iC) 104. 

The term "microcomputer" is intended to represent various devices 
including, but not limited to, devices such as microprocessors, 
microcomputers, controllers, and control computers that are 
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implemented using one or more integrated circuits and/or discrete 
components. Microcomputer 104 controls the passing of data ^ 
between interface 102 and other units within device 100 such as 
signal processing units (not shown in Figure lA). For example, if / 
5 device 100 is a DTR and bus interface unit 102 is receiving digital 
video data for recording, ^iC 104 ensures that interface 102 passes 
video and audio data to signal processing circuitry within device 100 
such that recording occurs as intended. Also, p.C 104 controls 
interface 102 so that interface 102 communicates data to and from' 
10 bus 130 in accordance with the appropriate bus protocol. 

Microcomputer 104 implements the desired bus protocol under 
control of a control program and data stored in memory 106. 
Memory 106 may include various types of memory including RAM,, 

1 5 ROM, EEPROM, and hard drive or other types of bulk storage devices. 

The control program may include routines for controlling functions of 
bus interface 102 such as enabling or disabling communication, 
coordinating bus operations with other operations within device 100, 
and formatting data for bus communication. 

20 

One aspect of controlling bus interface 102 that is provided by 
\iC 104 is determining how to resolve conflicting requests for use of 
resources within device 100. For example, consider the situation in 
which device 110 is a cable box. device 120 is a DSS satellite receiver, 

2 5 and unit 100 is a video tape recorder (VTR). A user may program 

VTR 100 to begin recording a particular program via cable box 110 at 
a particular time. A conflicting command causes DSS unit 120 to 
attempt to access VTR 100 while it is recording the program via cable 
box 110. Conventional systems resolve the described problem by 

3 0 either ignoring the attempted access by DSS unit 120 or by notifying 

the user that VTR 100 is unavailable. 

In accordance with an aspect of the invention, the system 
shown in Figure lA implements a lock manager for resolving 
3 5 resource conflicts in a manner described in detail below. In the 

exemplary embodiment shown in Figure lA, |iC 104 operates under / 
control of a "lock manager" routine included within the bus control 
program to insure that device 100 resolves conflicts in a manner 
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described in detail below. A "lock mechanism" 1070 routine is also 
be included within the bus control program; the operation of lock 
mechanism 1070 is described in the detailed description, of Figure 2. 
below. The lock manager provides for establishing communication 
5 relationships, or locking conditions, between devices coupled to bus 
130 and for determining under what conditions these relationships 
are modified. Operation of the lock manager involves parameters 
that are stored in a portion 107 of memory 106 and will be described 
in more detail below. Parameters associated with a lock relationship 

1 0 that are involved in resolving a conflict are stored within the lock 

manager region 107 of memory 106 in Figure lA. Three such 
parameters are persistence, locked address, and unlock condition. 
Figure IB illustrates these three parameters being stored as three 
separate entries 1071, 1072, and 1073 in memory region 107. It 
15 should be noted that, although not shown in Figure lA, devices 110 
^nd 120 each include features that provide functionality similar to 
that described herein as being provided by units 102, 104, 106 and 
107 within unit 100. The structure within units 110 and 120 may be 
similar to that shown within device 100, but similar functionality 

2 0 could be produced using other arrangements also. 

As an example of the operation of the lock manager, consider 
the conflict example described above. Using the lock manager, 
recording a program from cable box 110 using VTR 100 involves the 

2 5 bus control capability of cable box 110 transmitting a lock request to 

VTR 100. The lock request asks VTR 100 to establish a relationship, 
i.e., to establish a locked condition, with cable box 110. 
Microcomputer 104 receives the lock request via bus interface unit 
102 and determines whether or not VTR 100 is already locked to 

3 0 another device. If not, i.e., the VTR is available for locking, VTR 100 

sends a reply to cable box 110 indicating that the lock has been 
established in lock mechanism 1070. Recording of the desired 
program from cable box 110 proceeds and the lock relationship 
prevents interruption of the recording except under certain , 
3 5 conditions that are defined by parameters such as persistence and 

unlock condition described above and, in more detail, below, that are 
associated with the lock relationship. The value of these parameters 
is established by the locking device, i.e.. the unit initiating the lock 
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condition (cable box 110 in the present example) and are transferred 
to and stored in the locked device (the VTR in the present example) 
m respective portions of region 107 of memory 106. When DSS unit 
120 requires use of VTR 100, lock manager capability within DSS unit 
5 120 sends a lock request to VTR 100. Because a pre-existing lock 
relationship exists between VTR 100 and cable box 110 the lock 
manager within VTR 100 processes the lock request from DSS 120 in 
accordance with the parameters of the existing lock condition stored 
m VTR 100 and resolves the conflicting request in the manner 
1 0 described below. 

Figure 2 illustrates the operation of the locking mechanism 
1070 which cooperates with lock manager 107. Lock manager 107 
manages the relationships or locks that a "master device" initiates. ' 

1 5 Lock mechanism 1070 carries out the locking of the two devices 

together. When a master device desires to initiate a lock it sends a 
command to the slave device. A device may be in any one of various 
states involving lock control. Four such states, unlocked, locked, 
unlock request pending, and change lock pointer, are illustrated' by 

2 0 ovals 210, 220, 230 and 240 in Figure 2. Transitions between the 

states are illustrated by lines connecting the ovals. As shown at the 
top of Figure 2, a lock manager can receive requests including lock ' 
and unlock requests. As shown at the bottom of Figure 2. a lock 
mechanism can produce responses such as "grant.lock" or 

2 5 "lock_in_use" in response to requests. Also, a lock mechanism can 

produce an unlock request and a device error/reset indication. 

As shown in Figure 2, the system transitions from unlocked 
state 210 to locked state 220 in response to a lock request and issues 

3 0 a grant.lock response. A return to unlocked state 210 from locked 

state 220 occurs in response to a lock being released. Lock release 
occurs by transitions through states 230 and 240. In response to an 
unlock request, the system moves from state 220 to unlock request 
pending state 230. At state 230, the system processes parameters 
3 5 such as the persistence parameter and the unlock condition to 

determine whether a lock should be released. If the lock will not be 
dissolved, a lock_in_use message is sent and the system returns to 
locked state 220. If the lock can be dissolved, an unlock messaee is 



BNStXDCID: <WO 9817033A1J_> 



wo 98/17033 PCT/US97/18750 

9 

issued and the system transitions to state 240 in which the locked 
address, or locking pointer, is changed to that of the device now 
requesting a lock. Subsequently, the system transitions to locked 
state 220 and issues a grant_lock message. 

5 

The operation of the lock manager 107 and lock mechanism 
1070 under various conditions, i.e., during various types of 
transactions between devices, is illustrated in Figures 3 through 7. 
In Figure 3, a device B is not locked and, in response to a lock request 
1 0 from device A, device B establishes a lock with device A. 

In Figure 4, device B is locked to device C in response to a 
previous lock request and receives a conflicting lock request from 
device A. The persistence parameter is set at 0 meaning that device 

1 5 B need not request approval of unlocking from device C prior to 

unlocking and re-locking with device A. Device B must only evaluate 
the unlock condition parameter to determine whether or not to 
dissolve the lock with device C. 

2 0 In Figure 5, device B is locked to device C in response to a 

previous lock request from device C and the persistence parameter is 
set to 1. Device B sends an unlock request, also referred to as a 
"disinherit lock" request, to device C. The lock manager in device C 
determines whether to release the lock or not. In Figure 4, device C 

2 5 decides to maintain the lock and sends a "resource in use" message 

that is relayed to device A by device B. 

Figure 6 shows a transaction similar to that in Figure 4 (i.e., 
persistence = 1) except that device C responds to device A's lock 

3 0 request by dissolving device C's lock with device B. Thus, device C 

sends an unlock message to device B and device B subsequently 
grants a lock with device A. 

Figure 7 shows a transaction in which device B is locked to 
3 5 device C with the persistence equal to 0 and device A hails all locking 
managers indicating device A*s desire to lock with device B. Device C 
notifies device A that device C will release its lock with device B. 
Device A then sends a lock request to device B and, because the 
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persistence parameter is set to 0, device B locks to device A and can 
send a message to device C instructing device C to dissolve the lock 
with device B. 

Further it is within the scope of the present invention that only 
locking or master devices require lock managers 107 and that slave 
or lockable devices only employ lock mechanisms 1070. The 
operation of such a system is similar to the system described herein 



Further details regarding the lock manager aspect of the 
invention, including features of the lock manager in addition to those 
already described, are described below. For convenience only, the 
following detailed description includes aspects based on utilization of 
the CAL Programming Language; however, it should be noted that 
15 any suitable alternate programming language may be substituted 
therefor. 



Examples of Applications using Locking 

The following describes application in addition to those already 
2 0 described in which a locking relationship is required. In a first 

example, a device ("Device A") desires to download severaL-pae^eets of 
data into a remote device ("Device B"). Device A does not want the ' 
data placed in Device B to be overwritten until the downloading is 
complete. Normally, this function requires a Segmented Network 

2 5 Service in both devices. However, in accordance with this invention. 

Device A sets up a temporary locking relationship that insures it is 
the only device capable of writing to Device B. After the data 
transfer. Device A terminates the locking relationship and, "unlocks," 
Device B. 
30 

In a second example, an external device, such as a cable box, 
executes a program timer event. The cable box "locks" the VCR 
transport mechanism. This keeps the VCR in the record mode until 
the session ends or an override condition occurs. The cable box sends 

3 5 a Stop command to the VCR and unlocks the VCR at the end of the 

event. 
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In a third example, a device desires to display an OSD message 
for a period of time. The device locks the display to itself and sends 
the relevant display information. This display device displays the 
information for a period of time. The locked device is unlocked by 
5 either the locking device itself or by a conditional event, for example 
a time out. 

A special form of locking, "listening", is also implemented. 
Controlling and inter-operating with various devices requires the 
I 0 ability to know their status. A device that contains listening 

capability discriminates between broadcast reports sent out by a 
particular group of devices, e.g., devices located within a house. 

For example, status change information is automatically sent 
from one device to another. A VCR updates its motion mode status to 
a display device or a temperature sensor sends an update to an 
environmental manager. There are two problems with this 
approach. The first problem is determining where the report should 
go. The companion problem is for the receiving device to determine 
what reported information is important to its function. This occurs 
when there are multiple instances of the same device type, such as 
thermostats or security sensors, reporting to various sub-systems in 
the same house. There is a need to discriminate between sources of 
information. The listening function accomplishes this function. 

There are various applications of listening. Some are more 
dynamic than others. Environmental control is an example of stable 
(static) listening application. In such a system, the listening functions 
are relatively static after an initial setup function. These systems 
require a reliable and inexpensive means for listening. Issues such 
as security and special access are important. The system 
configuration occurs at installation and rarely changes with great 
frequency. 

3 5 This is in stark contrast to an A/V system. An A/V system is 

very dynamic. Devices are installed and removed with relative 
frequency. Source of video and request function cause the systems 
configuration to change rapidly and regularly. Playback, Record, 
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Display message, and Timer Events all require changes in the 
listening and locking of device. There is a need to change the 
listening source device from VCR to a DBS device in an instant. There 
IS also a great deal of inter-device listening. A TV may be listening 
to one device, an environmental system, for display while a cable box 
IS listening to the status of a VCR. 

There are various levels of locking and listening desired. In 
many instances, an application requires only a device level locking. 
However, there are cases when it is desirable to lock at an object 
level. (That is, a device may be comprised of more than one object, 
for example a device may have separate controllable functions within 
the device itself.) Once such situation is a VCR application where it 
could be desirable to lock the transport mechanism while allowing 

1 5 other devices to edit or add timer events. Likewise, although it is 

desirable to lock the display object in a TV to guarantee proper 
display, it is not desirable to lock the devices* ability to respond to 
other communications. 

2 0 The locking attribute has relational, conditional and inherited 

characteristics. An example of a conditional locking characteristic is 
when an object is already locked by a device. The unlocked objects 
are lockable; however, the device may not be lockable. In such a 
situation, the device is lockable only by the same device that locked 
2 5 one of its object. Inherited locking infers that all the objects in a 
device inherit the locked status of the object. 

The Lock Manager 

All devices that desire to lock other devices must have a "Lock 
Manager" which keeps track of all the active locks initiated by the 
device and is responsible for locking and unlocking remote devices. 
A structure of such a lock manager, implemented in CAL is provided 
below. 
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The above delineated parameters are described hereinbelow. 



1 . Lock_Pointer Definition 

Each record of the Data Memory memory_block instance 
5 variable (IV) is a pointer to the locked device,residing remotely on 
the network. The lock_pointer data includes three fields: (1) < 
Device Network Addrp^;^;^- (2) <Locked_Context_ID>; and (3) 
<L ocked„Objec tJ[D>. Those fields that are left blank are considered as 
nulT 

1 0 

The Device Network Address field is the network address of the 
locked device. In a CEBus application, the MAC address is used as 
the network address. 

1 5 The Locked_Context_ID field contains two bytes. The first byte 

is either a Context number or the context wildcard "DE". The DE 
wild card implies that the lock corresponds to all the instanciations of 
the same context in the device. The second byte is the 
Context_Class_ID. The remaining bytes are null. 



I 



1 0 



1 5 
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The Locked_Object_ID field is split into two bytes. The first 

byte is either the Object.Number or the Object wild card "00". When 
the object wild card is used the second byte is the Object_Class. 

When the wild card is not used, the second byte is null. This allows 
the locking of all objects within the same Object Class. 

2. Unlock Message Definition 

The locked device sends an unlock message to the Locking 
Manager. There are three defined unlock messages: (1) 
Device.Unlock; (2) Context_Unlock; and (3) Object Unlock. 

The unlock message is sent using a Macro, U4. The U4 macro 
contains two argument fields. The first argument contains the 
Device_Network_Address. The second argument contains the context 
and object information. The macro prototype is 

"<context_ID> <object_ID> U4 <data token> <size of data> <escape token> 
<Device_Network_Address> F5 xdata token> <size of data> <escape 
token> <Context_Number><Context_Class_ID><Object_ID><Object_Class>" 

2 0 When a context is locked the Context_Number and 

Context_Class_ID are placed in the second argument field, (the 
Object.ID and Object_Class are not supplied). The object information 
is null. 

2 5 When an object is locked, the Context_Number, 

Context_Class_ID, Object.ID and Object_Class are also supplied in the 
second argument. 

a) Device Unlock Message 

The Device_Unlock message must contain the locked device's 

3 0 <Device_Network_ Address >. The second argument is not contained 

in the message. 

"00 04 55 34 F5 F5 F4 34 F6 <Device_Network_Address>F5 " 
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Examples of Locking Pointing Vectors Placed in the Lock Manger Object 
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or Wild Card 
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Class_ID 
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Lock 


Locked_Address 










Context 
Lock 


Locked_ Address 


AO 


(9F)*00..9E 


01 




Specific 
Context 


Locked_ Address 


(DF)*AO..DE 


(9F)*00,,9E 


01 




All 

Context 
of Same 
Context 
Class 


Locked_ Address 


ce 


(DF)*AO..DE 


01 




All 

Context 
in Devic 


Locked_ Address 


DE 


00 


01 




Object 
Lock 


Locked_Address 


(DF)*AO..DE 


(DF)*AO..DE 


(3F)*0 1 
,.3E 


<Any 
Valuo 


All 

Objects 
i n 

Context 
Class 


Locked_ Address 


(DF)*AO..DE 


(DF)*AO..DE 


00 


<Any 
Valuo 
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Locking Device?; 

The . ability to lock a device is dependent upon locks previously 
put into place. Device locking requires that all other locks be 
overwritten. 



1 0 



1 5 



The Locking implementation uses the variables (IV) in the 
following table. The Locking_Address IV must be present in all 
implementations. The default level of persistence is "0." The 
following sub-sections contain a detail explanation of the TVs. 



IV 


R/W 


Type 


Name 


B (42) 


R/W 


N 


persistence 


E (45) 


R/W 


D 


Key_Entry 


G* (47) 


R/W 


D 


Locking_ Address 


O (4F) 


R/W 


D 


Unlock_Condition 



a) 



Persistence IV 

The Persistence IV influences the device's unlock behavior. 
There are presently three defined persistence levels: (0) Loose; (1) 
Tight; and (2) Listening. The persistence IV has a default level of 
Loose. When a device reverts to ah unlocked state it should set 
persistence to the default value. 



A loose locking level occurs when the persistence level is "0." 
Loose locking results in a device discriminating between devices that 
2 0 attempt to control it. However, the binding is loose. This means that 
the locked device may grant the request for a new lock with 
confidence that the previous locking device must dissolve the pre- 
existing lock. When the locking level is loose, the locking device 
should automatically release the lock upon request. This results in 

2 5 fast disassociation of previous locks and granting of new locks. 

When a loosely locked device receives a request to change the 
Locking. Address, it returns a completed message and sends a 
notification to the previous locking device to dissolve the lock. Loose 
locking infers any device can change the Locking_Address IV. 

3 0 Tight locking occurs when the persistence field is set to "I"; 

this allows only the locking device to change or grant permission to 
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change the Locking_Address IV. This is useful when a third device 
desires to create a lock with the . locked device. In this ca^e, the . third 
device queries the locked device. The locked device sends an unlock" 
message to the Lock Manager Object of the locking device. The 
5 locking device can either yield its lock or not yield its lock; that is the 
locking device returns a Completed Token, FE, when it dissolves the 
previous lock. Otherwise, the Locking Manager returns an FD Token 
with error-resource in use (8) code. 

1 0 Setting the persistence IV to "2" results in a form of locking 

called listening (as described above). In listening, the "locked" 
device binds itself to another device. A device can implement 
various levels of persistence depending upon its application. 

b ) Key_Entry IV 

The Key_Entry IV acts as a simple key into a locked device. 
This IV enables access to protected variables. This option can 
protect private functions, such as special diagnostic and setup 
operations, from general access. It also allows a device to 
discriminate between sources in the Listening application. 

There are two uses of the Key_Entry IV. The first is when a 
tight lock, (persistence = 1), is established. The locking device 
supplies a data type variable Key^Entry value that grants access to 
private areas of the device. This value is defined, for purposes of 
explanation, as the "lock_key." 

The second is in a listening application, (persistence = 2). The 
Listening Function uses the Key_Entry IV as an additional 
discriminator. An explanation of this Key_Entry function occurs later 
3 0 in this document. 

In addition to the first level of privacy, a manufacturer can 
choose to make the Key_Entry IV a protected variable that requires 
authentication. This separates the issue of special access and 
3 5 authentication. The Key_Entry IV is inactive when a device is 
unlocked or the persistence is not set to "loose". The default 
key_entry value is ''null". Whenever a device is unlocked or the 
persistence level is changed, the Key_Entry IV reverts to the default 



20 
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value. This results in only the locking device being able to supply 

or read a Key_Entry IV value. This allows only one device to access 
private data or functions. 

5 Depending upon the application, the "lock.key" can be a fixed 

key, placed in ROM, or a writeable key, such as a "trusted key." 
Normally there is only one valid Key_Entry value; however, there 
can be multiple valid Key_Entry IV values. A manufacturer can 
choose to make the lock_key IV writeable. Protected devices become 
1 0 private again by setting the Key_Entry IV to an invalid entry (e.g., 
logical length is 0) or a false value, by disarming the lock, or 
changing the lock persistence <> 1. 

c) Locking_Address IV 

The Locking_Address IV is a data type variable and is the 

1 5 network address that locked the device. In a CEBus application, the 

MAC address is used as the network address. 

A locking device initiates a lock with a device when it writes its 
network address into the appropriate Locking_Address IV. Once a 
lock is in place setting the Locking_Address IV to an invalid address 

2 0 (e.g., logical length is 0) disarms the lock. A lock request to a device 

that does not support locking results in a return Error - Invalid IV. 

d) Unlock_Condition IV 

A third variable is the Unlock.Condition IV which allows a user 
to specify a condition that automatically dissolves a lock. The unlock 
2 5 condition can use IV's found in the device, (this is similar to the 
Event Manager Object). 

The Unlocking_Condition IV contains a Boolean expression that 
defines the unlock condition for the device. The Boolean expression 
is a CAL expression, as defined in the CAL grammar. This program is 
waiting for some condition to occur within the device, such as a timer 
expiration or threshold crossing. The device dissolves the lock upon 
the specified unlock condition. Note that the unlock condition is in 
the locked device. The persistence level can be either loose or tight. 



30 



35 



A condition is loaded into the Unlock_Condition using the 
setArray method. In this case, the data being loaded is the actual 
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CAL condition program. This program includes the condition to 
watch for that will cause the unlock action. 

Just as. in the Event Manager Object, there are two slight 
5 differences in the CAL grammar for the Unlocking_Condition IV to 
operate correctly. The first difference is identifying the instance 
variables to watch. Rather than a simple IV identifier, the context 
and object location of the IV must be supplied. For example, instead 
of testing (current_value > max_value), the Unlocking_Condition 
1 0 would test (Audio Context, Volume Control, current^value > Audio 
Context, Volume Control, max_value). By requiring all bytes, the 
statement can be correctly parsed. 

The Boolean expression contained in Unlock__Condition allows 

1 5 for at most two relations to be evaluated. For example, the Clock 

Object could unlock when hour equals 12 or month equals 6. The 
first IV in the Boolean expression is the value reported. Along with 
the standard relational operators, an additional operator is defined, 
the DELTA operator. Note that when the Unlock_Condition IV is 

2 0 written to (using setArray Method), the object must check the 

validity of the condition being placed in the IV. If the condition is 
invalid, an Error-Bad Argument Type(I2) is returned and no 
Unlock_Condition occurs. 

Locking Implementation 

2 5 A device is locked by setting the Locking_Address IV to a 

valid destination address using the sclArray method. In the case of a 
CEBus application, the network address is composed of the Unit 
address and House Code appearing in MSB, LSB order. An example of 
a locking message using a Unit Code 0034, House Code 001 A, results 

3 0 in the following message: 



<coniext><object> 46 471 Ff5 Ff5 Ff4 34 Ff6 00 34 00 1 A 
(<context><object> setArray 'GA* <DEL> <DEL> <DATA> 34 <ESCAPE> 
0034 OOIA) 



5 
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Setting an object Locking_Address IV to an invalid address 
(e.g., logical length is 0) unlocks it. 

(<context><object> setArray GA' <DEL> <DEL> <DATA> 30 <ESCAPE>) 

An Error- Invalid IV is returned when this function is not 
supported. 

1. Object Locking Implementation 

Locking at the Object level is accomplished by setting the 
1 0 locking mechanism in the individual Object. 

2. Context Locking Implementation 

The object level locking is extensible to contexts. Locking at 
the context level is accomplish by setting the locking mechanism in 
the context control Object. 

1 5 

Setting the Locking. Address IV to a valid value locks the 
context. The objects instanciated in the context inherit the same 
Locking_Address. (This only applies when persistence <>2.) If an 
object within the context is already locked, the context cannot be 

2 0 locked unless the object Locking. Address IV value is the same as the 

context Locking_Address value. 

The context lock is initiated by writing the network address of 
the locking device into the Context_Locking_Address IV placed in the 

2 5 Context Control Object. 

<context_ID> 01 01 46 47 54 F5 F5 F4 34 F6 <Locking_Address> 

The Context_Persistence, Context_Key_Entry, 

3 0 Context_Locking_Address, and Context_Unlock_Condition TVs inherit 

their behavior from the Object IVs Persistence, Key_Entry, 
Locking_Address, and Unlock_Condition respectively. 

3. Device Locking Implementation 

Locking at the device level is accomplish by setting the device 
3 5 locking mechanism in the Node Control Object. The Node Control 
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Object can have its own individual Object locking mechanism. The 
device level locking variables are 





Node Control Object (01) Node 

Control 




Variables in Node Control Object that allow for Device Locking 


r IV 


: R/W 


Type 


Name- - ■ ; • 


Context Function 


o (6Fh) 


R 


d 


object_list 


list of objects used 
in context 


z (6a) 


R/W 


N 


Device_Persistence 


Persistence 


V (76) 


R/W 


D 


Device_Key_Entry 


Key_Entry 


T* (54) 


R/W 


D 


Devi ce_Loc king 
_Address 


Locking_ Ad dress 


V (56) 


R/W 


D 


Device_Unlock_Condition 


Unlock_Condition 



5 The Device_Persistence, Device_Key_Entry, 

Device_Locking_Address, and Device_Unlock_Condition IVs inherit 
their behavior from the Object IVs Persistence, Key_Entry, 
Locking_Address, and -Unlock_Condition respectively. 

1 0 The device lock is initiated by writing the network address of 

the locking device into the Device_Locking_Address IV. 

00 01 46 54 F5 F5 F4 34 F6 <Locking_Address> 
Locking Scenarios 

1 5 For the purposes of demonstration, the locking device is the 

device that desires to lock another device. The locked device is the 
device to be locked. Locking request can be made to either the 
device to be locked or to the lock manager holding the lock. Under 
normal conditions, a locking request is made by attempting to write 

2 0 a new address into the Locking_Address IV. The request can be 

either direct or conditional. 
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a) Direct Locking Request 

An example of. a locking message using a Unit Code 0034, 
House Code 001 A, results in the following message: 

<context><object> 46 4741 Ff5 Ff5 Ff4 34 Ff6 00 34 00 lA 
(<contextxobject> setAiray "G" <DEL> <DEL> <DATA> •4' <ESCAPE> 0034 
OOIA) 

The device must determine if it is lockable. . If the device, 
object, context is not locked a completed token FE is returned. The 
locking device places the locking pointer into the lock manger object. 

b) Conditional Object Locking Request 

An example of a locking message using a Unit Code 0034, 
House Code OOIA, results in the following message: 

<context><object> 56 47 F7 <context><object> 46 471 F5f5 Ff5 Ff4 34 
Ff6 00 34 00 1 A EB 44 47 F8 

<context><object> I(IF "G " <BEGIN> <context><object> setArray -G' <DEL> 
<DEL> <DATA> '4' <ESCAPE> 0034 OOIA <ELSE> setArray "G" <END> ) 

If the array "G" is not in use the device is locked. Otherwise, it 
will not lock the device. This method is used with resource locking. 
If the device is in use the requesting device can request "hail" the for 
the locking device to give up the lock, device by sending a broadcast 
message. 



c) Using LOCK Macro U2 

The LOCK Macro U2 is used to lock context and objects. The 
Macro message contains the Macro ID followed by the arguments list. 
3 0 There are two necessary arguments : (1) Locking_Address; and (2) 
persistence. An argument list is considered null if it is not filled. 
After a lock is established, the Key_Entry and Unlock_Condition IVs 
are updated. 

3 5 <context_ID> <object_ID> "U 2" <data token> <size of data> <escape 
token> <locking_address> F5 <persistence>F5 <Key_Entry> 
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As an example, for the CAL Macro message to lock a context 11: 
*'ll Oil 55U 322 F4 34 F6 OF 32 23 34 F5 01 " 

5 

The argument 0Ff32 2334 is the locking address, the 
persistence is set to 1. At this point, the locking device can send 
Entry_Key IV data and a Unlock_Condition. IV Data. 

1 0 When the Locking.Address is not supplied it is assumed to be the 

source address of the Macro Message. 

"11 01 55 32 F5 F5 01" 
Locking Release Request 

15 a) Locking Release Request to Locking Master 

(1) using DISINHERIT (option 1) 

If the object is locked, at either the object, context, or device 
level, then it will request that the impeding locks device relinquish 
its lock. The message is sent to the Locking Manger Object: 

20 

< Universal Context > < Locking Manager Object > • disinherit 
<lock_pointer (6C) > F4 [number of bytes] F6 <device_address> 
<context_id> <object> 

2 5 disinherit the lock with <device> <context> <object> 

The context_ID includes the context_number if it is not AO. If it is 
AO, the context number can be optionally included. 

3 0 (2) Using UNLOCK Macro U41 (option 21) 

The UNLOCK Macro U14 is sent to the EVENT Manager Object. 
The macro matches the desired locking pointer and request that it be 
deleted. If a match is present then the locking manager either grants 
the request or denied the request. If the locking device cannot be 
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found, the locked device dissolves the lock. See section 2.1.2 for 
details. 

Listening Implementation 

The listening function is a companion to the reporting method. 
Listening is implemented in objects that are interested in the status 
of other devices or network resources. An example of a network 
resource is time. 

A listening function allows a device to discriminate between 
broadcast messages containing status information. Listening function 
is a special application of the locking function. In the listening mode, 
the object does not inherit the locking state of the context or device. 
(This is necessary for listening function to perform correctly when a 
device or context is locked). 

In Listening, a device binds itself to another device. This 
means a device can set its own Locking_Address IV. The 
Locking_Address IV is either read only or read/write. The write 
option is actually a type of loose locking. The persistence IV is set to 
"2." The Key_Entry IV acts as a special access discriminator. The 
following table contains the listening IV list. 





Object Listening IV list 


IV 


R/W 


Type 


Name 


Context Function 


G* (47) 


R/W** 


D 


Locking_Address 


object listening address 


B* (42) 


R 


N 


Persistence 


2 = Listening 


E (45) 


R/W 


D 


Key_Entry 


allows special access 



When the Locking_Address is a read-only variable, the device 

2 5 sets its own locking address When the Locking_Address is set 

externally, the locking device does not place a lock_pointer in its 
Locking Manager. 

There are three different implementations of listening. The 

3 0 first method uses the source network address to gate access to the 

listening object. The object discriminates in favor of the source 
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device address corresponding to the Locking_Address IV. In this 
case, the message is written into the appropriate Instant Variable. 

The second and third listening implementations utilize the 
5 Key_Entry device. This implementation requires macro message. 
The macro message, Li, is used to deliver the Key_Entry value and 
the data simultaneously. The listening device verifies that the macro 
is from the correct source address and that the supplied Key_Entry 
value matches the desired value. 

10 1. Multi-Source Listening Implementations 

There are occasions when a listening object may desire to listen 
to all broadcast sources without discrimination. Once such situation 
occurs when a fire sensors broadcast that it is detecting a fire. It 
broadcast the information onto the network. A listening device 

1 5 wants to listen to all possible sources that would report a fire. 

In a general, the multi-source listening application is 
implemented by allowing a device receive the state of any device 
(sensor). This is denoted by setting the Locking_Address IV to a 

2 0 broadcast address. In a CEBus application, the listening discriminator 

is set to either all Unit_Addresses within a particular House Code or 
to all addresses on the network. The alarm author source or zone 
addresses included in the message; this can be extracted from the 
source_address field or a state vector contained in the message. 

2 5 2. Listening via Key_Entry and Locking_Address 

In this way, the lock_key value becomes a selector value that 
allows a device to discriminate between individual context and 
objects. For example, in the time context, the time type identifier 
can be supplied in the Macro Message. This value is checked for the 

3 0 desired time type. If a device has multiple instanciations of a 

reporting context, the device can include the context number in the 
Key_Entry field. The receiving node checks the incoming context 
number and verifies it is the one of interest, 

3 5 <context_ID> <object_ID> 53 31 F4 <size of data> <escape token> 5 
<Locking_Address> F5 <data token> <size of data> <escape token> 
<Key_Entry> F5 <Argument_Listmessage> 
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1 0 



In Listening, a device binds itself to another device. In the case 
of listening, a device can set its own Locking_Address IV. The 
Locking_Address IV can be either read only or read/write. 

3. Listening via Key_Entry 

Listening can also be accomplished by setting the 
Locking_Address to "00 00 00 00." In this case the only 
discriminator is the Key_Entry value. This allows an object to 
discriminate based on an access key. This is done as follows: 

<context_ID> <object_ID> 53 31 F5 00 00 00 00 F5 <data token> <size 
of data> <escape token> <Key_Entry> F5 <Argument_List> 

When the Locking_Address is read only, the device exclusively 

1 5 sets its own locking address. When a Locking_Addresss IV is R/W 

the locking is loose. The locking device does not place a 
locking_pointer in its Locking Manager. 

<context_ID> <object_ID> LI <data token> <size of data> <escape token> 

2 0 <Locking_ Address > F5 F5<message> 

There are some instances where a unique identifier is desired 
to allow discrimination between multiple context or objects in a 
single device. One example is a temperature sensor device that 

2 5 contains multiple sensors. It may be desirable to bind each sensor to 

a corresponding listening object. This is accomplished using the 
key_entry approach where if key_entry = null there is no 
discrimination. When Key_Entry is set to a value, the listening device 
requires the proper Key_Entry value before it will update the object 

30 

Example: Listening variable has a discriminator, like the key_entry 
number, which allows the user to set a discriminator. The data and 
discriminator are sent at Macro_ID key_entry F5 Listening DATA. If 
the Key_entry is not supplied, the discriminator is the network 

3 5 address. 
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While the invention has been described in detail with 
respect to numerous embodiments thereof, it will be apparent that 
upon a reading and understanding of the foregoing, numerous 
alterations to the described embodiment will occur to those skilled 
in the art and it is intended to include such alterations within the 
scope of the appended claims. 



wo 98/17033 



28 



PCT/US97/18750 



Claims 

1 . A device comprising: 

(a) means for communicating with at least a second?; device 
interconnected by a network bus, thereby creating a relationship 
between said first nientioned device and said second device, said 
communication means being capable of receiving query data from a 
third device; 

(b) first means for storing information pertaining to the 
persistence of said relationship; 

(c) second means for storing information pertaining to a 
condition for terminating said relationship; 

(d) means for controlling operating modes of said device in 
response to control data from said second device, said controlling 
means being capable of processing said relationship information and 
said query data and of terminating said relationship in response to 
one of said terminating condition and said query data. 

2. The consumer electronic device recited in Claim 1 wherein said 
relationship information comprises one of a first state wherein said 
relationship is terminated in response to said query data and a 
second state wherein said relationship is maintained regardless of 
said query data. 

3. The consumer electronic device recited in Claim 2 wherein 
terminating said relationship in response to said query data 
comprises forming a new relationship between said consumer 
electronic device and said third device, 

4. The consumer electronic device recited in Claim 3 wherein said 
controlling means is capable of polling said second device, in 
response to the receipt of said query data to obtain permission to 
terminate said relationship. 
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5, The consumer electronic device recited in Claim 4 wherein said 
controlling means is further capable pf monitoring the status of said 
second device. 

5 6. The consumer electronic device recited in Claim 5 wherein said 
controlling means is further capable of enabling said second device to 
alter information contained in said consumer electronic device. 

7. The consumer electronic device recited in Claim 1 wherein said 
1 0 predetermined condition is related to one of said relationship 

between said consumer electronic device and said second device and 
an internal condition of said device. 



8 . A device comprising: 
15 (a) means for communicating with at least a second device 

interconnected by a network bus, thereby creating a relationship 
between said first mentioned device and said second device, said 
communication means being capable of receiving query data from a 
third device; 

20 

(b) first means for storing information pertaining to the 
persistence of said relationship, wherein said relationship 
information comprises one of a first state wherein said relationship is 
terminated in response to said query data and a second state 

2 5 wherein said relationship is maintained regardless of said query 

data; 

(c) second means for storing information pertaining to a 
condition for terminating said relationship; 

30 

(d) means for controlling operating modes of said device in 
response to control data from said second device, said controlling 
means being capable of processing said relationship information and 
said query data and of terminating said relationship in response to 

3 5 one of said terminating condition and said query data. 
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9. A system having a plurality of devices interconnected to one 
another by a network bus, each device comprising: 

(a) means, for communicating with at least a second device 
over the network bus, thereby creating a relationship between said 

5 first mentioned device and said second' device, said communication 
means being capable of receiving query data from a third device; 

(b) first means for storing information pertaining to the 
persistence of said relationship, wherein said relationship 

1 0 information comprises one of a first state wherein said relationship is 
terminated in response to said query data and a second state 
wherein said relationship is maintained regardless of said query 
data; 



^ 5 (c) second means for storing information pertaining to a 

condition for terminating said relationship; 

(d) means for controlling operating modes of said device in 
response to control data from said second device, said controlling 
2 0 means being capable of processing said relationship information and 
said query data and of terminating said relationship in response to 
one of said terminating condition and said query data. 

10, A method for controlling a consumer electronic device 

2 5 connected on a network bus, the method comprising: 

(a) communicating with at least a second device 
interconnected by a network bus thereby creating a relationship 
between said consumer electronic device and said second device; 

3 0 (b) controlling operating modes of said consumer electronic 

device, at least one operating mode being controllable by said second 
device on said network bus, thereby creating a relationship between 
said consumer electronic device and said second device; 

3 5 (c) storing information pertaining to a persistence of said 

relationship and a predetermined condition pertaining to a condition 
for terminating said relationship; 
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(d) receiving query data from a third device; 

(e) processing said information pertaining to said significance 
of said relationship and said query data; and 

(f) terminating said relationship in response to one of said 
terminating condition and said query data. 

11. The method recited in Claim 10 wherein the step of terminating 
further comprises creating a new relationship between said 
consumer electronic device and said third device. 

12. The method recited in Claim 11 further comprising the step of 
polling said second device to obtain permission to terminate said 
relationship. 

13. The method recited in claim 12 further comprising the step of 
monitoring the status of said second device. 

14. The method recited in Claim 13 further comprising the step of 
enabling said second device to alter information contained in said 
consumer electronic device. 
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